IBIS Macromodel Task Group Meeting date: 11 June 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Randy to send out an updated [C Comp Model] BIRD draft explaining rules that cover the case when an I/O or 3-state model has one capacitance model. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 4 meeting. Bob moved to approve the minutes. Arpad seconded the motion. There were no objections. ------------- New Discussion: BIRD197.3_draft_4(DC_Offset): Arpad noted that Fangyi had prepared a presentation with examples but had been unable to attend the previous meeting. The group had reviewed the presentation at the previous meeting but deferred full discussion until Fangyi was back. Fangyi shared the presentation and noted that he had made minor changes. The presentation uses examples to illustrate the two mathematically equivalent approaches. Case 1 - Rx simple gain example. - Input is a single ended waveform between 0V and 1V. - gain stage with gain value of 3. - Slicer. - We would expect the ideal threshold at the slicer to be 1.5V (given the waveform varying between 0V and 3V after the gain stage), but assume in this example the model decides the slicer threshold is 1.6V - The input waveform to GetWave(), as has been agreed upon since the first draft of this BIRD, will be a differential signal. In this case it will vary between -0.5V and 0.5V, and the EDA tool will pass in a DC_Offset value of 0.5V. - approach 1: - The model recovers the single-ended waveform. - The model applies the gain and sets the slicer threshold at 1.6V. - The model assumes the EDA tool always uses a 0V threshold to compare the GetWave() output waveform. So, it subtracts 1.6V from the waveform and GetWave() returns a waveform between -1.6V and 1.4V. - approach 2: - The model recovers the single-ended waveform. - The model applies the gain and sets the slicer threshold at 1.6V. - GetWave() returns the raw slicer input waveform between 0V and 3V. - The model returns the threshold of 1.6V. - The EDA tool uses the 1.6V threshold to compare the GetWave() output waveform. Case 2 - Rx device is a simple comparator. - A non-ideal reference voltage is provided for VrefDQ (0.4V in this case). - Input is again a single-ended waveform between 0V and 1V. - The input waveform to GetWave(), as has been agreed upon since the first draft of this BIRD, will be a differential signal. In this case it will vary between -0.5V and 0.5V, and the EDA tool will pass in a DC_Offset value of 0.5V. - The voltage waveform after the comparator would vary between -0.4V and 0.6V. - In this example we assume the model sets the slicer threshold at -0.1V (though 0.1V might be the expected value). - approach 1: - The model assumes the EDA tool always uses a 0V threshold to compare the GetWave() output waveform. So, it subtracts -0.1V from the waveform and GetWave() returns a waveform between -0.3V and 0.7V. - The EDA tool compares the output waveform with a 0V threshold to determine the logic level. - approach 2: - GetWave() returns the raw slicer input waveform between -0.4V and 0.6V. - The model returns a threshold of -0.1V. - The EDA tool compares the output waveform with -0.1V. Summary: approach 1: GetWave() output is the slicer waveform minus the threshold voltage. approach 2: GetWave() output is the slicer waveform itself. Model must return the threshold voltage. Fangyi noted that we took approach 2 for PAM4. Walter noted his agreement with details of the examples Fangyi provided. He said it's really the issue of who's responsible for the shifting. The model could output the threshold and ask the EDA tool to handle it (approach 2), or the model could shift the output waveform itself (approach 1). Walter noted that for PAM4 we had multiple thresholds, only upper and lower were really needed since the center threshold was still nominally zero, but we added three parameters. With multiple thresholds the model couldn't just do a simple shift like it can in this case. Walter reiterated his preference for approach 1, since EDA tool behavior would not have to change. He asked why we would adopt approach two when it's not required and forces tool behavior to be altered. Walter noted that approach 2 would require a new "DC_Threshold" parameter, and Init() would have to return a value for it, but only GetWave() would return a meaningful value. Arpad asked if one parameter could serve multiple purposes. For example, if the value returned by Init() represented the DC_for_Statistical, and the value returned by GetWave() represented the "DC_Threshold." Walter referred to work Bob is doing on the EMD proposal and noted the decision there that we can't have the same parameter name do two different things. Arpad noted that we now have 2 or possibly 3 new parameters for this BIRD: - DC_Offset - passed into GetWave() - DC_for_Statistical - returned by AMI Init(), required because Init() can only return an IR not a waveform. - DC_Threshold - returned by GetWave() IF we adopt approach 2. Walter noted that since he's the original author and is not in agreement with approach 2, he would prefer Fangyi, or someone advocating for approach 2, introduce a motion to adopt approach 2 so we could vote on it. Fangyi agreed, but said he would prefer to hear from chip makers and others first. Walter suggested Fangyi prepare a modified draft with approach 2. Arpad asked if the threshold parameter required by approach 2 would be part of the same BIRD. Fangyi said he would simply add the new threshold parameter to the existing BIRD draft. Ambrish asked Fangyi why we would want to adopt approach 2 if approach 1 works. Fangyi said one reason was what Arpad had pointed out in email discussions, if you want to compare the output of GetWave() with something you could measure in the lab, with approach one there will be an offset between the measured waveform and the output of GetWave(). Curtis said with approach 1 neither the user nor the EDA tool knows how much the model shifted the GetWave() output waveform before returning it. Arpad asked Fangyi to email his presentation to the ATM list. He also suggested Fangyi list all the options and consequences of approach 1 or approach 2. Complex C_comp modeling: Arpad noted the previous week's discussion of how to handle the case in which only one Mode was covered by a [C Comp Model] for a two-mode top-level model (I/O or 3-state). Randy had produced an updated draft stating that we fall back to [C Comp Corner] for any Mode not covered by a [C Comp Model]. Arpad noted that there had been some discussion of making [C Comp Model]'s Mode(s) consistent with the submodel use of modes. But Arpad expressed concern, which he had sent in an email to ATM, that submodels were restricted to one submodel per model. So, they were already inconsistent with what was being proposed for [C Comp Model]. Bob and Curtis noted that they thought Arpad's interpretation of the spec's statement that "submodel mode cannot conflict with the top-level model type" was too narrow. It's only a conflict if the submodel mode is not supported by the top-level model (e.g. driving mode for an Input is a conflict). It's not a conflict if the mode is a subset of what is supported by the top-level model (e.g. driving mode for an I/O is okay). Bob also thought it was possible to have multiple submodels under a two-mode top level model like I/O or 3-state, but no one was certain at the time. (note: page 95 of IBIS 7.0 says it is possible: "When special-purpose functional detail is needed, the top-level model can call one or more submodels.") Arpad noted that he thought the requirement that a [C Comp Model]'s Mode must be specified was unnecessary. If the model were an Input for example, the only possible mode was implicit (non-driving), and having it specified only made extra work for the parser to check for inconsistencies. Arpad noted that the mode column is required for submodel, but asked if we wanted to maintain consistency with that requirement. Bob said he understood Arpad's point, but the he thought specifying it all the time makes a model easier to read and understand. He also noted that the parser already does such checking for other things. Arpad said he wouldn't object to leaving it as is. Arpad noted that he thought the fallback rules Randy had proposed could be simplified. He proposed a statement that says for an I/O or 3-state model if only one Mode is covered by a [C Comp Model] then fall back to [C Comp Corner] for the other Mode. Arpad noted that further discussion will be needed. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Fangyi to prepare a version of the DC_Offset BIRD utilizing approach #2. AR: Fangyi to send his DC_Offset BIRD presentation to ATM. ------------- Next meeting: 18 June 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives